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ABSTRACT 


The  problem  of  generalizing  functional  specifications  for 
WHILE  loops  is  considered.  This  problem  occurs  frequently  when 
trying  to  verify  that  an  initialized  loop  satisfies  some  func¬ 
tional  specification#  i.e.  produces  outputs  which  are  some  func¬ 
tion  of  the  program  inputs. 

The  notion  of  a  valid  generalization  of  a  loop  specification 
is  defined.  A  particularly  simple  valid  generalization#  a  base 
generalization,  is  discussed.  A  property  of  many  commonly  occur¬ 
ring  WHILE  loops,  that  of  being  uniformly  implemented,  is 
defined.  A  technique  is  presented  which  exploits  this  property 
in  order  to  systematically  achieve  a  valid  generalization  of  the 
loop  specification.  Two  classes  of  uniformly  implemented  loops 
which  are  particularly  susceptible  to  this  form  of  analysis  are 
defined  and  discussed.  The  use  of  the  proposed  technique  is 
illustrated  with  a  number  of  applications.  Finally,  an  implica¬ 
tion  of  the  concept  of  uniform  loop  implementation  for  the  vali¬ 
dation  of  the  obtained  generalization  is  explained. 


KEYWORDS  and  PHRASES:  program  verification,  valid  generalization, 
base  generalization,  uniformly  implemented  loop,  iteration  condi¬ 
tion  j 

C  F.  CATZGOF I E  S :  5.24 

i 


Generalizing  Specifications  Por  Uniformly  Implemented  Loops 


1.  Introduction 

Consider  the  problem  of  proving/disproving  a  WHILE  loop 
correct  with  respect  to  some  functional  specification  f,  i.e.  f 
requires  the  output  variable (s)  to  be  some  function  of  the  inputs 
to  the  loop.  If  the  loop  precondition  is  weak  enough  so  that  the 
domain  of  f  contains  the  intermediate  states  which  appear  after 
each  loop  iteration,  the  loop  is  said  to  be  closed  for  the  domain 
of  f.  An  important  result  in  program  verification  is  that  if  the 
loop  is  closed  for  the  domain  of  its  specification,  there  are  two 
easily  constructed  verification  conditions  based  solely  on  the 
specification,  loop  predicate  and  loop  body  which  are  necessary 
and  sufficient  conditions  for  the  partial  correctness  of  the  loop 
with  respect  to  its  specification  [Mills  75,  flisra  78],  If  the 
loop  is  not  closed  for  the  domain  of  the  specification  function, 
a  generalized  specification  (i.e.  one  that  implies  the  original 
specification)  which  satisfies  the  closure  requirement  must  be 
discovered  before  these  verification  conditions  can  be  con¬ 
structed  (this  problem  is  analogous  to  that  of  discovering  an 
adequate  loop  invariant  for  an  inductive  assertion  proof  [Hoare 
59]  of  the  program)  . 

'•;e  remark  that  the  restricted  specification  often  occurs  in 
the  process  of  analyzing  an  initialized  WHILE  loop,  i.e.  one  that 
consists  of  a  '7HIL2  loop  preceded  by  some  initialization  code. 
This  initialization  typically  takes  the  form  of  assignments  of 
constant  values  to  some  of  the  variables  manipulated  by  the  loop. 
Examples  include  setting  a  counter  to  zero,  a  search  flag  to 
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FALSE ,  a  queue  variable  to  some  particular  configuration,  etc. 
It  is  clear  that  the  initialized  loop  is  correct  with  respect  to 
some  specification  if  and  only  if  the  WHILE  loop  by  itself  is 
correct  with  respect  to  a  slightly  modified  specification.  This 
specification  has  the  same  postcondition  as  the  original  specifi¬ 
cation  and  a  precondition  which  is  the  original  precondition 
together  with  the  condition  that  the  initialized  variables  have 
their  initialized  values.  Since  the  initialized  variables  will 
typically  assume  other  values  as  the  loop  iterates,  the  loop  most 
likely  will  not  be  closed  for  the  domain  of  this  specification 
and  a  generalization  of  it  will  be  necessary  in  order  to  verify 
the  correctness  of  the  program. 


The  term  vO  appearing  in  the  poatcondi t ion  refers  to  the  initial 
value  of  v.  The  program  is  correct  if  and  oniy  if 


{ z=Q ,v>=0 , k  >  =  G } 
wh i 1 e  v  >  0  do 
z  :  -  z  +  TT7 

v  :*  v  -  1 

O'! 

( z=vO*fc } 


is  correct.  Since  this  loop  precondition  requires  z  to  have  the 


f 
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value  0  and  z  assumes  other  values  as  the  loop  executes,  the  loop 
is  not  closed  for  this  precondition.  Thus,  before  this  program 
can  be  verified  using  the  above  mentioned  technique,  this  specif¬ 
ication  must  be  generalized  to  something  like 

{v>*0,k>=0} 
while  v  >  0  do 
z  :=  z  +  FT 
v  :•  v  -  1 
od 

{z=zO  +  vO*k] 

where  zO  refers  to  the  initial  value  of  the  variable  z. 

The  approach  to  this  problem  suggested  here  is  one  of 
observing  how  particular  changes  in  the  value  of  some  input  vari¬ 
able  (e.g.  z  in  the  example)  affect  the  result  produced  by  the 
loop  body  of  the  loop  under  consideration.  Clearly  in  general,  a 
change  in  the  value  of  an  input  variable  may  cause  an  arbitrary 
(and  seemingly  unrelated)  change  in  the  loop  body  result.  In 
many  commonly  occurring  cases,  however,  the  result  produced  by 
the  loop  body  is  "uniform"  across  the  entire  spectrum  of  possible 
values  for  the  input  variable.  It  is  this  property  that  will  be 
exploited  in  order  to  obtain  a  generalized  specif ication  for  the 
loop  being  analyzed.  The  generalizations  considered  here  have 
the  property  that  the  loop  is  correct  with  respect  to  the  gen¬ 
eralization  if  and  only  if  the  loop  is  correct  with  respect  to 
the  original  specification.  Thus  if  the  loop  is  closed  For  the 
domain  cf  the  generalization,  the  program  can  be  proven/d ispr oven 
by  testing  its  correctness  relative  to  the  genera’  ization. 
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We  remark  that  the  general  problem  of  finding  a  suitable 
generalized  loop  specification  has  been  shown  to  be  vp-complete 
[Wegbreit  77],  i.e.  it  appears  quite  unlikely  that  there  will 
ever  exist  an  easily  applied  procedure  for  obtaining  such  gen¬ 
eralizations  that  will  work  in  all  cases.  On  the  other  hand, 
work  presented  here  and  elsewhere  [3asu  &  Misra  76,  Misra  79, 
Basu  30],  indicates  that  generalized  specif ications  can  be 
obtained  in  a  systematic  manner  for  restr icted  classes  of  loops. 
We  feel  that  the  notion  of  "uniform"  loop  body  behavior  discussed 
in  this  paper  is  valuable  not  only  as  a  tool  by  which  such  gen¬ 
eralizations  may  be  obtained,  but  also  as  an  attempt  at  a  charac¬ 
terization  of  loops  which  are  susceptible  to  routine  analysis, 
and  hence  in  this  sense,  easy  to  verify  and  comprehend. 


The  following  section  defines  the  necessary  notation  and 
terminology  and  then  introduces  the  idea  of  a  general ized  loco 
specification.  Section  3  defines  a  uniformly  implemented  loop 
and  states  several  implications  of  this  definition  for  the  prob¬ 
lem  of  generalizing  a  specification  for  such  a  loop.  "hose 
results  are  applied  on  several  example  programs  in  Section  4.  In 
Section  5,  a  simplified  procedure  is  suggested  for 
proving/ lisproving  a  uniformly  implemented  loop  correct  "ith 
respect  to  the  obtained  generalization.  Finally,  several  guide¬ 
lines  for  recognizing  uniformly  implemented  loops  are  presents! 
in  Section  3. 


i 
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2.  Preliminaries 

We  will  consider  a  verification  problem  of  the  form 

{<z,X>  e  D{f ) } 
while  B (z ,x)  do 

z,X  :  =  h'  (z  ,X)  ,h~(z,X) 
od 

{ <z ,X>  =  f (<zO,XO>) } . 

In  this  problem,  f  is  a  data  state  to  data  state  function.  The 
data  state  consists  of  two  variables,  z  and  X.  The  notation  D(f) 
means  the  set  of  states  in  the  domain  of  f  (i.e.  the  set  of 
states  for  which  f  is  defined)  .  The  terms  zO  and  XO  refer  to  the 
initial  values  of  z  and  X  respectively.  The  effect  of  the  loop 
body  is  partitioned  into  two  functions  h'  and  h"  which  describe 
the  new  values  of  z  and  X  respectively. 

The  loop  will  be  referred  to  as  P.  The  data  state  to  data 
state  function  computed  by  the  loop  (which,  presumably,  is  not 
explicitly  known)  will  be  denoted  [P]  .  Thus  D([P])  is  the  set  of 
states  for  which  P  terminates.  As  a  shorthand  notation  we  will 
use  Y  for  the  state  <z,X>,  and  K  for  the  data  state  to  data  state 
function  computed  by  the  loop  body,  i.e. 

'T(Y)  =  II ( < z , X > )  =  <h'  (z,X)  ,h"  (z,X)  >. 

Suppose  the  loop  is  not  closed  for  D(f)  in  that  this  ret 
contains  only  a  restricted  collection  of  values  (maybe  only  one) 
of  z  and  that  other  intermediate  values  of  z  occur  as  the  loop 
iterates.  The  variable  z  will  be  called  the  key  variable .  Our 
goal  here  is  to  discover  some  more  general  specification  f' 
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includes  each  of  these  intermediate  values  of  the  key  variable  in 
its  domain.  This  generalization  process  (in  one  form  or  another) 
is  necessary  for  a  proof  of  correctness  of  the  program  under  con¬ 
sideration. 

Definition  -  P  is  correct  with  respect  to  (wrt)  a  function  f 
if  and  only  if  (iff)  for  all  Y  in  D(f),  [P] (Y)  is  defined  and 
[P] (Y)=f (Y) . 

Definition  -  A  superset  f "  of  f  is  a  valid  generalization  of 
f  iff  if  P  is  correct  wrt  f,  then  P  is  correct  wrt  £' . 

Note  that  the  collection  of  supersets  of  f  is  partially 
ordered  by  "is  a  valid  generalization  of."  The  following  theorem 
defines  one  technique  for  constructing  a  valid  generalization  of 
the  specification  function  f. 

Theorem  1  -  A  superset  g  of  f  whose  extension  is  defined  by 
(1)  ~B(Y)  ->  g  (Y)  *Y 

is  a  valid  generalization  of  f. 

Proof  -  Suppose  P  is  correct  wrt  f.  Let  Y  <=  D(g)  .  If  Y  € 
C(f),  the  loop  handles  the  input  correctly  by  hypothesis.  If  Y 
is  not  in  D(f),  we  must  have  ~3(Y)  and  g(Y)=Y.  Thus  the  program 
and  g  map  Y  to  itself  and  thus  are  in  agreement.  Consequently  P 
is  correct  wrt  g,  and  g  is  a  valid  generalization  of  f. 

"’he  theorem  utilizes  the  fact  that  the  loop  must  necessarily 
compute  the  identity  function  over  inputs  where  the  loop  pre'J'- 
cate  is  false.  Combining  this  information  with  the  program 
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specification  f  results  in  a  valid  generalization  of  f. 

We  note  that  if  there  does  not  exist  a  superset  g  of  f  whose 
extension  is  defined  by  (1),  the  theorem  is  vacuously  true.  This 
would  occur  if  an  element  Y  from  the  domain  of  f  satisfied  ~B(Y) 
as  well  as  f(Y)/Y  (this  would  imply  that  the  program  was  not 
correct  wrt  f) .  If  there  does  exist  a  superset  g  of  f  whose 
extension  is  defined  by  (1) ,  the  superset  is  unique.  Throughout 
this  report,  we  will  refer  to  the  function  g  as  the  base  general¬ 
ization  of  the  specification  f. 

Def inition  -  A  valid  generalization  £'  of  f  is  adequate  if 
the  loop  is  closed  for  D(f"). 

The  important  characteristic  of  an  adequate  valid  generali¬ 
zation  £'  is  that  it  can  be  used  to  prove/disprove  the  correct¬ 
ness  of  P  wrt  the  original  specification  f.  Since  the  loop  is 
closed  for  D(f*),  P  can  be  proven/di spr oven  correct  wrt  f*  using 
standard  techniques  ivills  72,  Mills  75,  3asu  &  M.isra  75,  Morris 
&  Wegbreit  77,  Wegbreit  77,  Misra  78].  Specifically,  p  is 
correct  wrt  £*  iff  each  of 

(2)  the  loop  terminates  for  all  Y  6  P(f') 

( 3)  Y  €  D(f')  &  ~3 (Y)  ->  f'(Y)=Y 

(4)  Y  €  D(f')  &  3  (Y)  ->  f'(Y)=f'(II(Y)  ) 

hold.  If  P  is  correct  wrt  £' ,  then  P  is  necessarily  correct  wrt 
any  subset  of  £' ,  including  f.  If  P  is  not  correct  wrt  £' ,  then 
by  the  definition  of  a  valid  generalization,  ?  must  not  be 
correct  ■,rt  f. 
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Example  2  -  The  following  program  tests  whether  a  particular 
key  appears  in  an  ordered  binary  tree. 


{ success=FALSE} 

while  tree  f  NULL  and  “success  do 

if  name (tree)  =  key  then  success  :=  TRUE 
elseif  name (tree)  <  key  then  tree  :=  right (tree) 
else  tree  :=  left(tree)  fi 

od 

{success  =  IN(treeO,key) } 


The  function  IN(treeO,key)  appearing  in  the  postcondition  is  a 
predicate  which  means  "the  ordered  binary  tree  treeO  contains  a 
node  with  name  field  key."  The  boolean  variable  success  is 
chosen  as  the  key  variable  since  it  is  constrained  to  the  value 
FALSE  in  the  input  specification.  Thus  success  plays  the  role  of 
z  and  the  pair  of  variables  <tree,key>  correspond  to  X  in  the 
program  schema  discussed  above.  The  specification  function  f  is 
f (<FALSE, tree*key>)  =  <IN (tree, key) , tree' ,key'> 
where  tree"  and  key'  are  the  final  values  of  the  variables  tree 
and  key  computed  by  the  loop,  respectively.  That  is,  since  the 
final  values  of  these  variables  are  not  of  interest  in  this  exam¬ 
ple,  we  specify  these  final  values  so  as  to  be  automatically 
correct.  Using  Theorem  1,  a  valid  generalization  of  this  specif¬ 
ication  is 

g (<success , tree , key>)  =  if  “success  then 

<IN (tree, key) ,tree',key'> 
else  if  tree=NUTL  o£  success  then 
<success , tree , key> , 


which  is  equivalent  to 
c  (< success  , tree, key >) 


<succesr  or  I" (tree, key) ,tree' ,key'> . 


-3- 
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In  this  example,  the  domain  of  the  base  generalization  g  of 
f  includes  each  value  of  the  key  variable,  (i.e.  FALSE  and  TRUE) 
and  is  thus  adequate.  Consequently,  this  generalization  can  be 
used  to  prove/disprove  the  correctness  of  the  program. 

In  most  cases,  however,  the  heuristic  suggested  in  the 
theorem  is  insufficient  to  generate  an  adequate  generalization. 
Indeed,  the  base  generalization  is  an  adequate  generalization 
only  in  the  case  when  the  sole  reason  for  the  closure  condition 
not  holding  is  the  existence  of  potential  final  values  of  the  key 
variable  (e.g.  TRUE  in  the  example)  which  are  absent  from  D(f) . 
In  order  to  obtain  a  generalization  that  includes  general  values 
cf  the  key  variable,  an  important  characteristic  of  the  loop  body 
which  seems  to  be  present  in  many  commonly  occurring  loops  will 
be  exploited. 

3 .  Uniformly  Implemented  Loops 

Pe fin  it  ion  -  Let  ?  be  a  loop  of  the  form  described  above. 
Let  A  he  a  set,  and  let  Z  be  the  sot  of  values  the  key  variable  z 
may  assume.  Let 

:  A  x  Z  ->  2 

he  an  infix  binary  operator.  The  loop  ?  is  uniform1 y  implement ~ J 
with  respect  to  (wrt)  iff  each  of 

(5)  T3(z,X)  ->  h'  (a  $'  n,X)  =  a  h'  (z,X) 

(5)  B(2,X)  ->  $'  z,X)  =  h "  <  z ,  V ) 

(7)  2(z,X)  ->  U(a  z#M) 


hoi*. 
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Conditions  (5)  and  (6)  of  this  definition  state  that  a 
modification  to  the  key  variable  by  the  operation  $'  causes  a 
slight  but  orderly  change  in  the  result  produced  by  the  loop 
body.  The  change  is  slight  because  the  only  difference  in  the 
result  produced  by  the  loop  body  occurs  in  the  key  variable. 
This  difference  is  orderly  because  it  corresponds  precisely  to 
the  same  $"  operation  that  served  to  modify  the  input  value  of 
the  key  variable.  Condition  (7)  specifies  that  such  a  modifica¬ 
tion  does  not  cause  the  loop  predicate  B  to  change  from  TRUE  to 
FALSE. 

As  a  shorthand  notation  we  define  the  infix  operator  $  as 
a  $  Y  =  a  $  <z,X>  =  <a  $'  z,X>. 

In  this  notation  (5) -(7)  are  equivalent  to 
(8)  B  (Y)  ->  a  $  H  ( Y)  =  H  (a  $  Y) 
and 

B  (Y)  ->  B  (a  $  Y)  . 

Example  3  -  Consider  again  the  program  from  Example  1  which 
multiplies  natural  numbers  using  repeated  addition: 

{ z=0 ,v>=0 , k>=0 } 
while  v>0  do 
z  :  =  z  +  k ; 
v  :  =  v  -  1 

{ z=vQ*k } . 


Let 

z  be  the  key  variable 

.  Tho 

pair 

<v,  '<> 

corresponds 

to  the 

var 

table  X  occurring  in 

the  above  sch 

ema . 

The  loop  is 

uni formly 

imp 

lamented  vrt  +  ,  whore 

A  and 

Z  are 

both 

the  set  of 

natural 
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numbers.  Note  that  adding  some  constant  to  the  input  value  of  z 
has  the  effect  of  adding  the  same  constant  to  the  value  of  z  out¬ 
put  by  the  loop  body.  Now  consider  the  following  alternative 
implementation  of  multiplication: 

{ z=0 , v>=0 , k>=0 } 
while  v>0  do 

TF  z<k  tEen  z  :=  z  +  k 

iTseif  z=k  then  z  :=  z  *  2  *  v 

else  z  :=  z  -  k  f i ; 

v  :=  v  -  1 
od 

{z=vU*k} . 

Again,  let  z  be  the  key  variable.  This  loop  is  not  uniformly 
implemented  wrt  +.  Intuitively,  this  is  due  to  the  high  degree 
of  dependence  of  the  loop  body  behavior  on  the  value  of  the  key 
variable.  The  result  of  this  dependence  is  that  adding  some  con¬ 
stant  to  the  value  of  z  causes  an  unorderly  change  in  the  value 
of  z  output  by  the  loop  body. 

The  reader  may  wonder  if  the  second  multiplication  program 
above  might  be  uniformly  implemented  wrt  some  operation  other 
than  +.  b'e  remark  that  any  loop  is  uniformly  implemented  wrt  S' 
:  A  x  Z  ->  2  defined  by 
a  $'  z  =  z 

for  all  a  €  A  and  z  e  Z.  For  the  purpose  of  this  report,  we  rule 
out  such  trivial  operations,  i.e.  ve  require  that  for  any  z  <=  2, 
there  exists  seme  a  5  A  such  that 
a  z  /  z. 

;7ith  this  assumption,  there  does  not  exist  can  operation  wrt  which 
the  second  of  the  above  loops  is  uniformly  implemented  (or  more 
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briefly#  the  loop  is  not  uniformly  implemented) .  To  see  this, 
suppose  the  loop  were  uniformly  implemented  wrt  $"  :  A  x  Z  ->  Z. 
Select  z*0,  a  6  A  such  that  a  $“  0  f  0,  and  k=a  $"  0.  We  evalu¬ 
ate  condition  (5)  as  follows: 


B  (z 

,X) 

-> 

h"  (a  $' 

z,X) 

=  a 

h' 

(z,X) 

i.e. 

v  > 

0 

-> 

h"  (a  $' 

o 

A 

< 

V 

=  a 

3' 

h' 

(0 ,<v,k>) 

i.e. 

v  > 

0 

-> 

h' (k,<v 

,k>) 

=  a 

h' 

(0,<v,k>) 

i.e. 

V  > 

0 

-> 

k*2*v 

=  a 

h" 

A 

> 

V 

V 

O 

which  implies 

v>0  &  k>0  ->  k*2*v  =  a  $'  k. 

Since  the  term  k*2*v  will  vary  with  different  values  of  v  where  k 
is  positive,  and  a  $'  k  is  independent  of  v,  this  condition  is 
false  and  thus  (5)  does  not  hold.  We  conclude  that  the  second 
multiplication  program  above  is  not  uniformly  implemented.  That 
is,  there  does  not  exist  a  nontrivial  modification  that  can  be 
applied  to  the  variable  z  which  always  resu1ts  in  a  slight  and 
orderly  change  in  the  result  produced  by  the  loop  body. 

The  results  presented  here  are  based  on  the  following  lemma 
concerning  uniformly  implemented  loops.  The  lemma  describes  the 
output  of  the  loon  for  some  modified  input  a  $  Y  (i.e.  [?] (a  $ 

Y) )  in  terms  of  the  output  of  the  loop  for  the  input  Y  (i.e. 
[?](Y))  and  the  output  of  the  loop  for  the  input  a  $  [P] (Y)  (i.e. 
IP] (a  3  IP] (Y>)>. 

Lemma  1  -  Let  P  be  uniformly  implements'"  wrt  O'.  ",*'en 

(1)  Y  6  D(  [?] )  ->  [P]  (a  $  Y)  =  [P]  (a  3  [?]  (Y)  )  . 


/ 
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Proof  -  We  use  induction  on  the  number  of  iterations  of  P  on 
Y.  For  the  base  case  of  0  iterations,  [?1(Y)=Y,  and  the  lemma 
holds.  Suppose  it  holds  for  Y  values  requiring  n-1  iterations 
where  n  >  0,  Let  Yl  require  n  iterations.  Since  n  >  0,  B(Yl) 

holds.  By  (7),  B(a  $  Yl) .  Note  that  H(Yl)  requires  n-1  itera¬ 
tions  on  P;  thus  by  the  inductive  hypothesis 
[PI  (a  $  H ( Yl) )  =  [P]  (a  $  [P]  (H (Yl) ) )  . 

Due  to  the  uniform  implementation  this  is 

[P](H(a  $  Yl))  •  [Pi (a  $  [P] (H (Yl) ) ) . 

Using  the  loop  property  B (Y)  ->  [P] (Y) = [P] (H (Y) )  on  both  sides  we 
get 

[PI  (a  $  Yl)  =  [P]  (a  $  [P]  (Yl)  )  . 

Thus  the  inductive  step  holds  and  the  lemma  is  proved. 

The  general  idea  behind  our  use  of  the  lemma  is  as  follows. 
Suppose  the  value  [P] (Y)  is  known  for  some  particular  Y.  I.e. 
suppose  we  know  what  the  loop  produces  for  the  input  Y.  In  addi¬ 
tion,  suppose  that,  given  the  result  [P] (Y) ,  the  quantity  [P] (a  $ 
[ P ] (Y) )  is  also  known.  With  this  information,  we  can  then  use 
Lemma  1  to  "solve"  for  the  (possibly  unknown)  value  [ P ] (a  $  Y) . 
This  additional  information  concerning  the  input/output  behavior 
of  the  loop  can  he  used  as  an  aid  in  constructing  a  valid  gen¬ 
eralization  of  the  specification  f. 

■Tow  can  v;e  find  the  value  [P]  (Y)  and  then  the  value  [P]  (a  $ 
[?] (Y) )  for  some  Y?  The  key  lies  in  assuming  the  loop  P  is 
correct  wrt  f.  If  P  is  not  correct  vrt  !,  any  generalization  of 
f  obtained  by  the  technique  will  be  a  valid  generalization  by 
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definition.  Under  this  assumption,  IP] (Y)  is  known  for  Y  6  D(f) , 
i.e.  Y  6  D(f)  ->  [P] (Y) =f (Y) ,  and  hence  Lemma  1  implies 

(10)  Y  6  D(f )  ->  [P]  (a  $  Y)  *  [P]  (a  $  f  (Y) )  . 

Consider  now  the  base  generalization  g  of  f  defined  in 
Theorem  1.  Recall  that  g  is  simply  f  augmented  with  the  identity 
function  over  the  domain  where  the  loop  predicate  B  is  false. 
Assuming  as  before  that  P  is  correct  wrt  f,  P  is  then  correct  wrt 
g  by  Theorem  1;  hence  Y  6  D(g)  ->  [P]  (Y)  **g  (Y)  .  Thus  (10)  implies 

(11)  Y  €  D(f )  &  a  $  f  (Y)  6  D(g)  ->  [P]  (a  $  Y)=g(a  $  f(Y)). 

Thus  we  can  "solve"  for  the  behavior  of  the  loop  on  the  input  a  $ 
Y,  assuming  Y  €  D(f),  a  $  f (Y)  6  D(g)  and  P  is  correct  wrt  f. 
This  suggests  that  the  superset  £'  of  f  whose  extension  is 
defined  by 

(12)  Y  €  D  (f )  &  a  $  f  (Y)  6  D(g)  ->  £'  (a  $  Y)=g(a  $  f  (Y)  ) 

is  a  valid  generalization  of  f.  Defore  giving  a  formal  proof  of 
this  result,  however,  we  first  consider  the  question  of  the 
existence  of  such  a  superset.  Specifically,  it  could  be  that  for 
some  a  and  Y  satisfying  Y  6  D(f)  and  a  $  f (Y)  ®  D(g) ,  that  a  $  Y 
S  D ( f )  and  f(a  S  Y)  f  g(a  $  f  (Y) ) ,  which  would  imply  f (a  $  Y)  / 
£"(a  $  Y)  .  In  this  case,  a  valid  generalization  of  f  base'5  on 

(12)  cannot  exist  (it  would  have  to  be  ambiguously  defin'd).  The 
following  theorem  states  that  this  implies  P  is  not  correct  vrt 
f . 

Theorem  2  -  If  P  is  correct  wrt  £,  there  exists  a  superset. 
i*  of  ?  whose  extension  is  defined  by  (12) ,  i.e. 

Y  €  h(?)  &  a  h  f  (Y)  <=  D(g)  ->  £'(a  $  Y)=g(n  5  f(Y)). 
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Proof  -  Let  f"  be  the  function  computed  by  the  loop,  i.e. 

IP].  Since  P  is  correct  wrt  f,  P  is  correct  wrt  g,  and  f"  is  a 

superset  of  both  f  and  g.  By  the  lemma 
f  "*  (a  $  Y)  *  f'(a  $  £*  (Y) ) 

for  all  Y  6  D(f).  Since  f'(Y)=f(Y)  for  Y  6  D(f)  and  f>(Y)*g(Y) 
for  Y  €  D(g),  (12)  holds.  The  subset  of  £'  which  contains  f  and 
whose  extension  is  defined  by  (12)  satisfies  the  theorem. 

The  following  theorem  is  the  central  result  presented  here. 

The  theorem  formalizes  the  use  of  Lemma  1  in  the  manner  suggested 

above,  i.e.  that  the  superset  described  in  the  previous  theorem 
is  a  valid  generalization  of  the  original  specification. 

Theorem  3  -  A  superset  £'  of  f  whose  extension  is  defined  by 
( 12) ,  i.e. 

Y  e  0(f)  &  a  $  f (Y)  €  D(g)  ->  f ' (a  $  Y) =g  (a  $  f(Y)), 
is  a  valid  generalization  of  f. 

Proof  -  Suppose  P  is  correct  wrt  f.  Let  Y  *3  D(f)  and  a  $ 
f(Y)  6  D(g).  By  Lemma  1  [P]  (a  $  Y)  =  [Pi  (a  $  l?](Y)).  Since  P 

is  correct  wrt  f  this  is  [P] (a  $  Y)  *  [P] (a  $  f(Y)).  By  Theorem 

1,  P  is  correct  wrt  g.  Using  this,  the  equality  can  be  written 
as  [?] (a  $  Y)  =  g(a  $  f (Y) ) .  Substituting  using  (12)  yields 
[P] (a  $  Y)  *  f ' (a  $  Y) .  Thus  P  and  £'  are  in  agreement  on  the 

input  a  $  Y  and  consequently  are  in  agreement  on  any  input  in 

D(f').  Hence  ?  is  correct  v/rt  f'  and  thus  £'  is  a  valid  general¬ 
ization  of  f. 

-If- 
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The  significance  of  Theorem  3  is  that  it  provides  a  guide¬ 
line  for  generalizing  the  specification  of  a  uniformly  imple¬ 
mented  loop.  If  the  loop  is  closed  for  the  domain  of  the  result¬ 
ing  specification,  the  generalization  can  then  be  used  to 
prove/disprove  the  program  correct  wrt  the  original  specifica¬ 
tion. 

4.  Applications 

In  this  sect?.*'  .  *>e  illustrate  the  use  of  Theorem  3  with  a 
number  of  example  programs  which  fall  into  either  of  two 
subclasses  cf  uniformly  implemented  loops.  The  subclasses 
correspond  to  the  two  possible  circumstances  which  can  occur  when 
a  $  f (Y)  of  condition  (125  belongs  to  the  set  D(g):  the  first, 

because  ~B(a  5  f (Y) ) ,  and,  the  second,  because  a  $  f (Y)  €  D(f). 
In  each  of  these  situations,  condition  (12)  takes  on  a 
particularly  simple  form. 

Definition  -  A  uniformly  implemented  loop  satisfying 
~2(Y)  ->  ~3 (a  $  Y) 
is  a  a  loop. 

Observe  that  this  condition  along  with  (7)  indicates  that  a 
Type  A  uniformly  implemented  loop  satisfies 
3 ( Y)  <->  B(a  $  Y) , 

i.e.  the  value  of  the  loop  predicate  3  is  independent  of  a  change 
to  the  data  state  by  the  operator  $. 
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The  intuition  behind  a  Type  A  uniformly  implemented  loop  is 
as  follows.  Whenever  an  execution  of  a  Type  A  loop  terminates 
(i.e.  ~B(Y)  holds)  and  the  resulting  data  state  is  modified  by 
the  operator  $,  the  result  is  a  new  data  state  which,  when  viewed 
as  a  loop  input,  corresponds  to  zero  iterations  of  the  loop  (i.e. 
the  predicate  B  is  still  FALSE  despite  the  modification) .  This 
property  is  reflected  in  the  following  corollary. 

Corollary  _1  -  Let  P  be  a  Type  A  loop.  A  superset  f'  of  f 
whose  extension  is  defined  by 

(13)  Y  6  D ( f )  ->  f  "  (a  $  Y) =a  $  f(Y) 
is  a  valid  generalization  of  f. 

Proof  -  The  proof  consists  of  showing  that  (12)  and  (13)  are 
equivalent  for  a  Type  A  loop  which  is  correct  wrt  f.  By  Theorem 

3,  the  corollary  then  holds.  Let  P  be  a  Type  A  loop  which  is 

correct  wrt  f.  A  consequence  of  the  correctness  property  is  that 
~B(f(Y))  for  all  Y  6  D(f) .  Since  P  is  a  Type  A  loop,  this  im¬ 
plies  ~3  (a  ?  f (Y) )  .  Thus  a  $  f (Y)  6  D(g)  and  g(a  $  f(Y))=a  $ 

f (Y) .  Consequently  (12)  and  (13)  are  equivalent. 

Of  course,  once  a  generalization  f  has  been  obtained  via 
Corollary  1,  there  is  no  reason  why  that  result  cannot  he  fed 
back  into  the  corollary  to  obtain  a  (possibly)  further  generali¬ 
zation  f"  (using  f'  for  f,  f"  for  f'5  .  "'his  notion  suggests 
the  following  general  case  of  Corollary  1. 

Corollary  2  -  let  ?  be  a  Type  A  loop.  A  superset  e'  of  f 
whose  extension  is  defined  by 
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Y  6  D (f )  &  n>0  -> 

f  (al$  (a2$  ...  (an$Y)  ...  ))»al$(a2$  ...  (an$f(Y))  ...  ) 
is  a  valid  generalization  of  f. 

Example  4  -  Consider  the  following  program  to  compute  ex¬ 
ponentiation. 

{w=l,c>0,d>=0} 
while  d  >  0  do 

if  odd(d)  then  w  :=  w  *  c  f i ; 
c  : =  c* c;  d : =d/2 
od 

{ w=cfT~ ^  dO} 

The  infix  operator  A  appearing  in  the  postcondition  represents 
integer  exponentiation.  In  this  example,  w  plays  the  role  of  the 
key  variable  z,  and  the  pair  <c,d>  corresponds  to  the  variable  X. 
We  now  consider  wrt  what  operation  the  loop  might  be  uniformly 
implemented.  For  any  operation  (7)  holds  (because  w  does  not 

appear  in  the  loop  predicate)  as  does  (6)  (because  the  values 
produced  in  c  and  d  are  independent  of  v) .  Furthermore,  (5)  must 
hold  for  inputs  which  bypass  the  updating  of  w.  "hus  the  unifor¬ 
mity  conditions  reduce  to 

d  >  0  S  odd  (d)  ->  (a  $'  v')  *  c  =  a  $'  (w  *  c) 

Tue  to  its  associativity,  it  is  clear  the  loop  is  uniformly  im¬ 
plemented  wrt  *,  where  the  sets  A  and  Z  are  the  set  of  integers. 
Since  the  key  variable  does  not  appear  in  the  loop  predicate,  it 
is  necessarily  a  r*’ype  A  loop.  Let  c>  0  and  ]>  =0 .  The  specifica¬ 
tion  function  hero  is 

f  (<l,c,d>)  =  <c  A  -\cVr> 

where  c'  and  are  the  fina1  values  computed  by  the  loop  for  the 
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variables  c  and  d.  Applying  Corollary  1, 

£'  (<a*l,c,d>)  =  <a*(c  A  d),c',d'> 
is  a  valid  generalization  of  f.  Since  this  holds  for  all  a,  the 
definition  of  £'  can  be  rewritten  as 

f*(<w,c,d>)  =  <w*  (c  *  d),c‘',d">. 

The  generalization  £'  is  adequate  and  can  thus  be  used  to  test 
the  correctness  of  the  program  wrt  the  original  specification. 
Applying  (2),  (3)  and  (4)  from  above,  these  necessary  and  suffi¬ 
cient  verification  conditions  are 

-  the  loop  terminates  for  all  c>0,  d>=0, 

-  <3=0  ->  w=w*  (c  ~  d)  ,  and 

-  w*(c  *  d)  is  a  loop  constant  (i.e.  cC  *  JO  =  w*  (c  ~  cl)  is 

a  loop  invariant) , 

respectively.  In  Section  5,  we  will  discuss  a  simplification  of 
the  last  of  these  verification  conditions  which  applies  for  uni¬ 
formly  implemented  loops. 

Example  £  [*iisra  71]  -  The  following  program  constructs  the 
preor-’er  traversal  of  a  binary  tree  with  root  node  r.  The  pro¬ 
gram  uses  a  stack  variable  st  and  records  the  traversal  in  a  se¬ 
quence  variable  sec. 

;seq=TULL,  st=(r)  /*  stack  st  contains  only  the  root  no-’e  r  */} 
wh  j  1  o  nt  f  TTlpov  rlo 

p- <=  st;  /*  pop- the  top  off  the  stack  */ 

sec  :=  s eg  J  J  name (p)  ;  /*  concatenate  name  of  p  to  req  */ 
if  right  (p)  ?  TIL  then  st  <-  right(p)  f i ;  /*  push  onto  st  * f 
]T  l?ft(?j  f  ::IL  then  st  <=  left(p)  fj_ 

r», 

•f  c-  (  r-  '  1 


Thu  function  ??TOTnT'®(r)  appearing  in  the  postcondition  is  the 
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sequence  consisting  of  the  preorder  traversal  of  the  binary  tree 
with  root  node  r.  Let  seq  be  the  key  variable.  The  same  reason¬ 
ing  employed  in  the  previous  example  indicates  here  that  the  loop 
is  uniformly  implemented  wrt  | | ,  where  the  sets  A  and  Z  are  the 
set  of  all  strings.  It  is  a  Type  A  loop.  The  specification 
function  is 

f  (<NULL,  (r)  >)  =  <PREORDER(r)  ,st'*>. 

Again,  the  "  notation  is  used  to  represent  the  final  values  of 
variables  that  are  of  no  interest.  Applying  Corollary  1  we  ob¬ 
tain 

V  (<seq, <r) >)  =  <seq|  | PREORDER (r)  ,  st"> 
as  a  valid  generalization  of  f.  In  this  case,  £'  is  not  adequate 
since  it  does  not  specify  a  behavior  of  the  loop  for  arbitrary 
values  of  the  stack  st.  We  will  return  to  this  example  after 
considering  another  subclass  of  uniformly  implemented  loops. 

Definition  -  A  uniformly  implemented  loop  satisfying 
~3(Y)  ->  a  $  Y  <=  D (f ) 
is  a  Type  3  loop. 

'"he  intuition  behind  a  Type  3  uniformly  implemented  loop  is 
as  follows.  Whenever  an  execution  of  a  ""ypo  3  ’’coo  terminates 
(i.e.  ~3(Y)  holds)  and  the  resulting  data  state  is  modified  by 
the  operator  $,  the  result  is  a  new  data  state  which  is  a  "valid" 
starting  point  for  a  new  execution  of  the  loop  (i.e.  this  now 
state  is  in  D(f)).  This  property  is  reflected  in  the  following 
corollary. 
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Corollary  3  -  Let  P  be  a  Type  B  loop.  A  superset  f"  of  f 
whose  extension  is  defined  by 

(14)  Y  e  D  ( f )  ->  f "  (a  $  Y)  =f  (a  $  f  (Y)  ) 
is  a  valid  generalization  of  f. 

Proof  -  The  proof  consists  of  showing  that  (12)  and  (14)  are 
equivalent  for  a  ’’’ype  B  loop  which  is  correct  wrt  f.  By  Theorem 

3,  the  corollary  then  holds.  Let  P  be  a  Type  3  loop  which  is 

correct  wrt  f.  A  consequence  of  the  correctness  property  is  that 
”8 { f (Y) )  for  all  Y  6  D (f ) .  Since  P  is  a  Type  B  loop,  this  im¬ 
plies  a  $  f (Y)  6  D (f ) .  Thus  a  $  f(Y)  6  D(g)  and  g(a  $  f(Y))=f(a 

$  f (Y) ) -  Consequently  (12)  and  (14)  are  equivalent. 

As  before,  a  general  case  of  this  corollary  can  be  stated 
which  corresponds  to  an  arbitrary  number  of  its  applications. 

Corollary  £  -  Let  P  be  a  Type  3  loop.  A  superset  f*  of  f 
whose  extension  is  defined  by 
Y  €  U(f)  &  n>0  -> 

V  (ai$ (a2$ ( . . . $ (an$Y) . . . ) ) ) «f (al$f (a2$f ( . . $f (anSf (Y) )...))) 
is  a  valid  generalization  of  f. 

example  £  (continued)  -  We  now  consider  the  problem  of 
further  generalizing  the  derived  specification  in  the  previous 
example.  The  variable  for  which  the  loop  is  not  closed,  st,  will 
now  be  the  key  variable.  Consider  an  operation  a  $'  st  that  has 
the  effect  of  adding  an  element  a  to  the  stack  sf.  Before  be  jpg 
.more  precise  about  this  operation,  we  consider  how  the  loop  body 
works,  an'5  how  its  output  depends  on  the  value  of  the  !;ey  vnri- 
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able  st. 

We  observe  that  the  loop  body  behavior  relies  heavily  on  the 
characteristics  of  the  node  on  the  top  of  the  stack.  Consequent¬ 
ly,  a  modification  a  $"*  st  to  st  which  pushed  a  new  node  a  onto 
the  top  of  st  would  not  cause  a  slight  and  orderly  change  in  the 
result  produced  by  the  loop  body  and  the  uniformity  conditions 
(5) -(7)  would  not  hold.  However,  because  the  loop  body  behavior 
seems  to  be  independent  of  what  lies  underneath  the  top  of  the 
stack,  we  suspect  the  loop  is  uniformly  implemented  wrt  ADDUNDER, 
where  A  is  the  set  of  binary  tree  nodes,  Z  is  the  set  of  stacks 
of  binary  tree  nodes,  and  a  ADDUNDER  st  is  the  stack  that  results 
from  adding  a  to  the  bottom  of  st.  Conditions  (5) -(7)  for  this 
operation  indicate  that,  indeed,  this  is  the  case. 

Let  f  be  the  generalization  l'  from  the  previous  example. 
In  keeping  with  the  convention  described  above,  since  st  is  now 
the  key  variable,  we  will  reverse  the  order  in  which  the  two 
variables  appear  in  the  data  state,  i.e.  we  will  write  <st,seo> 
instead  of  <seq,st>. 

Che  program  is  a  '"ype  3  uniformly  implemented  loop  since 
St=EM?TY  ->  <a  ADDTTDER  st,seq>  6  D(f) 
where  a  is  a  node  of  a  binary  tree,  and  specifically 
(15)  st=Zi-.PCY  ->  f  (<a  ADDURDER  st ,  seq>)  =<st'  ,  seq  (  |  RRECRRZE  (a)  >  . 
Applying  Corollary  4,  if  (r,an,  ...  ,al)  is  an  arbitrary  stack 
(with  r  on  top,  al  on  the  bottom) 
f  '  (<  (r  ,a r.,  ...  ,ai)  ,seq>)  = 
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f"(al$(a2$(  ...  $ (an$< (r) ,seq>)  ...  }))  = 
f (al$f (a2$f  (  ...  $f (an$f (<(r) ,seq>) )  ...  )))  = 
f  (al$f  (a2$f  (  ...  $f(an$<st'*,seq|  |  PREORDER  (r)  >)  ...  ))). 

Recall  that  st'  refers  to  the  final  value  of  st  computed  by  the 
loop.  The  loop  predicate  indicates  this  will  always  be  the  value 
EMPTY.  Hence  (15)  can  be  applied  from  inside  out  giving 
f (al$f (a2$f (  ...  $<st' ,seq | | PREORDER (r ) | | PREORDER (an) >  ...  ))) 

•  •  • 

<st',seq| ] PREORDER (r) | j PREORDER (an) | |  ...  | | PREORDER (al) > . 

This  resulting  specification  can  be  used  to  prove  the  correctness 
of  the  program. 

Example  5  [Gries  79;!  -  The  following  program  computes 

Ackermann's  function  using  a  sequence  variable  s  of  natural 
numbers.  The  notation  s ( 1)  is  the  rightmost  element  of  s  and 
s (2)  is  the  second  rightmost,  etc.  The  sequence  s(..3)  is  s  with 
s(2)  and  s(l)  removed. 

<3 (1) +1> 

<s (2) -1 , 1> 

<s(2)-l,s(2)  ,s  (1)  -1>  fi 

The  function  A(m,n)  appearing  in  the  postcondition  in  Ac Hermann's 
function.  The  specification  function  is 

f  (<s(2)  ,s  (1)  >)  =<A(s  (2)  ,s(l))>. 

Let  s  be  the  key  variable.  As  the  loop  body  behavior  is  indepen¬ 
dent  of  the  leftmost  portion  of  s,  the  loco  is  uniformly  inpls- 
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{ s=<m,n> ,m>=0 ,n>»0 } 
while  size(s)  f  1  d.o 

Tf  s(2)=0  then  s:«s(..3) 
e] sei f  s  ( 1) =0  then  s:*s(..3) 
else  s :  =s  ( .  .  3) 

od 

fs*<A(m,n) >} 


I 


Generalizing  Specifications  For  Uniformly  Implemented  Loops 


mented  wrt  | ,  where  A  is  the  set  of  natural  numbers,  Z  is  the  set 
of  sequences  of  natural  numbers,  and  a|s  =  <a>||s.  The  program 
is  also  a  Type  B  loop.  By  Corollary  4, 
f ' (<s  (n) ,s (n-1) ,  ...  ,s(l)>)  = 

f  "  (s  (n)  $  (s (n-1) $ (  ...  $ (s (3) $<s (2) ,s (1) >)  ...  )))  = 
f  (s(n)$f  (s(n-l)$f  (  ...  $f  (s(3)$f  (<s(2)  ,s  (1)  >)  )  ...  )))  = 
f  (s(n)$f  (s(n-l)$f  (  ...  $f  (s(3)$<A(s(2)  ,s(l)>)  ...  )))  = 
f  (s(n)$f  (s(n-l)$f  (  ...  $f  (<s(3)  ,A(s(2)  ,s(l)  )>)  ...  )))  * 
f  (s(n)$f  (s(n-l)$f  (  ...  $<A{s  (3)  ,A(s  (2)  ,  s  (1)  ) )  >  ...  ))) 

*“  •  •  •  “ 

<A(s (n) ,A(s (n-1) ,  ...  ,A(s (3) ,A(s (2) ,s ( 1) ) )  ...  ))> 
is  a  valid  generalization  of  f. 

j>.  Simplifying  the  "Iteration  Condition" 

The  view  of  WHILE  loop  verification  presented  here  is  one  of 
a  two  step  process,  the  first  step  being  the  discovery  of  an  ade¬ 
quate  valid  generalization  f"  of  the  loop  specification  f,  the 
second  being  the  proof  of  3  basic  conditions  (i.e.  (2)— (4) )  based 
on  this  generalization.  We  have  seen  that  the  uniform  nature  of 
a  loon  implementation  may  be  used  in  the  first  step  as  an  aid  in 
liecovering  an  appropriate  generalization.  In  this  section,  ve 
will  exploit  the  same  loop  characteristic  to  substantially  sim¬ 
plify  one  of  the  conditions  which  must  be  proven  in  the  second 
step  of  this  process. 

The  verification  condition  of  interest  is  (4)  above,  i.e. 

Y  6  D(f")  &  3 (Y)  ->  f"{Y)«ff'(H(Y>), 
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and  is  labeled  the  iteration  condition  in  [Misra  78] .  This  con¬ 
dition  assures  that  as  the  loop  executes,  the  intermediate  values 
of  Y  remain  in  the  same  level  set  of  £'  ,  i.e.  the  value  of  f"  is 
constant  across  the  loop  iterations.  Previously  we  argued  that 
if  P  is  uniformly  implemented  wrt  $"*,  a  change  in  the  key  vari¬ 
able  by  causes  a  slight  but  orderly  change  in  the  result  pro¬ 
duced  by  H.  Roughly  speaking  then,  the  behavior  of  H  is  largely 
independent  of  the  key  variable.  If  f"  is  chosen  so  as  to  be 
equally  independent  of  the  key  variable,  and  the  above  condition 
holds  for  Y=<z,X>  where  X  is  arbitrary  but  the  key  variable  z  has 
a  specific  simple  value,  we  might  expect  the  condition  to  hold 
for  all  Y.  Such  an  expectation  would  be  based  on  the  belief  that 
the  truth  or  falsity  of  this  condition  would  also  be  largely  in¬ 
dependent  of  the  key  variable. 

We  formally  characterize  this  circumstance  in  the  following 
definition . 

Definition  -  Let  P  be  a  loop  of  the  form  described  above.  A 
generalization  £'  of  f  is  represented  by  f  iff 


(15) 

Y  £  n(f  ) 

&  2  (Y) 

->  f  (Y)  sf  '  (!T  (Y)  ) 

(17) 

Y  <=  n(f') 

s  3(Y) 

->  f  "  (Y)  =f  ■*  (H  ( Y)  ) 

Thus  ic  f"  is  represented  by  f,  condition  (16)  can  be  use'3 
in  place  of  the  iteration  condition  (17)  in  proving  the  loop  is 
correct  wrt  f'  (and  hence  wrt  f) .  The  significance  of  this  si¬ 
tuation  is  that  the  iteration  condition  can  be  tested  with  the 
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key  variable  constrained  by  initialization  (as  prescribed  in 
D (f ) )  .  In  practice,  the  result  is  one  of  having  to  prove  a  sub¬ 
stantially  simpler  verification  condition. 

The  following  theorems  state  that  the  use  of  Corollaries  2 
and  4  lead  to  generalizations  which  are  represented  by  the  origi¬ 
nal  specif ication. 

Theorem  4  -  Let  P  be  a  Type  A  loop.  Suppose  l*  is  the  valid 
generalization  of  f  defined  in  Corollary  2.  Then  £'  is 
represented  by  f. 

Proof  -  Suppose  (15)  holds  and  select  some  arbitrary  Y"  from 
D(f')  satisfying  B(Y').  Thus  there  exists  al,  ...,  an  5  A,  n>*0 
and  Y  £  D ( f )  such  that 

Y'  =  al$ (a2$  (  ...  $ (an  $  Y  )  ...  )). 

By  the  definition  of  a  Type  A  loop,  we  must  have  3(Y).  Applying 
the  definition  of  £'  yields 

r (Y')=al$(a2$(  ...  $ (an$f  (  Y  )  ...  )) 

which  is 

*ai$ (a2$  (  ...  $ (anSf " (H (Y) )  ...  )) 
by  (16)  since  3(Y)  holds.  Since  H(Y)  £  P(f") ,  there  exists  bl, 
...,  bn  £  A,  n>=0 ,  and  Yl  £  D(f)  such  that 

H(Y)  =bl$  (b2$ (  ...  $ (bm$  Yl  )...)). 

Furthermore , 

. '  (:•  (Y)  )  =bl$  (b23  (  ...  S  (bmSf  (Yl)  )  ...  )). 

Tierce,  continuing  from  above 

C  *  (Y"* )  =  al$(  ...  $  (an$  (bl$  (  ...  $('^n$f(Yl))  ...  )))  ...  ) 
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which  is 

■f ' (al$ (  ...  $(an$(bl$(  ...  $(bm$  Yl  )...)))...)) 
from  the  definition  of  f“.  Thus 

t*  (Y")  *f  "*  (al$  {  ...  $  (an$H  ( Y) )  ...  )) 
which  is 

■f ' (H (al$ {  ...  $ (an?  Y  )  ...  ))) 
from  the  uniformity  condition  (8) .  Hence 
f'(Y')=f'(H(Y')) 
and  the  theorem  is  proved. 

Theorem  5  -  Let  P  be  a  Type  B  loop.  Suppose  f"  is  the  valid 
generalization  of  f  defined  in  Corollary  4.  Then  f"  is 
represented  by  f. 

Proof  -  Suppose  (16)  holds  and  select  some  arbitrary  Y'  from 
D(f')  satisfying  B(Y').  Thus  there  exists  al,  . ..,  an  ?  A,  n>=0 
and  Y  €  D ( f )  such  that 

Y'  =  al$(a2$(  ...  $ (an  $  Y  )...)). 

"e  ma.'<e  the  assumption  that  B(Y).  Otherwise,  by  the  definition 
of  a  Type  3  loop,  the  term  an  $  Y  can  be  replaced  by  another  Y  a 
0(£).  Since  3(Y"),  this  process  can  be  continued  until  Y'  is 
written  in  the  form  above,  with  Y  g  D(f)  and  B(Y).  Applying  the 
definition  of  f'  yields 

f'(Y')=f (at$f (a2$f (  ...  $f (ar.$f  (  Y  ))  ...  ))) 
which  is 

*f  (al$f  (a2$f  (  ...  5f  (an$f*tt(Y>))  ...  5)) 
by  (13)  since  3(Y)  holds.  Since  :-T(Y)  g  D(f'),  there  axists  hi, 
...,  tm  g  A,  m>*0,  and  Yl  g  0(f)  such  that 
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H (Y)  »bl$(b2$(  ...  $(bm$Yl)  ...  )). 

Furthermore, 

£' (H(Y) )=f (bl$f (b2$f {  ...  $f (bm$f (Yl) )  ...  ))). 

Hence,  continuing  from  above 

£'  (Y“*)  *f  (al$f  (  ...  $f  (an$f  (bl$f  (  ...  $f  (bm$f  (Yl) )  ...  )))  ...  )) 
which  is 

=f'  (al$  (  ...  $ (an$ (bl$ (  ...  $(bm$Yl)  ...  )))  ...  )) 
from  the  definition  of  f'.  Thus 
£'  (Y" )  -£'  (al$  (  ...  $  (an$H  (Y)  )  ...  )) 
which  is 

=f  ■*  (H  (al$  (  ...  $  (an$  Y  )...))) 
from  the  uniformity  condition  (8) .  Hence 
£' (Y')-t'  (H(Y')  ) 
and  the  theorem  is  proved. 

Example  1_  -  Consider  the  exponentiation  program  of  Example 
4.  The  generalization  obtained  from  Corollary  2  is 
f  ■*  (w,c,d>»<w*  (cM)  ,  c  '  ,  d  "  > . 

Since  £'  is  represented  by  f,  the  iteration  condition  correspond¬ 
ing  to  (1G) 

d>0  &  odd  (d)  ->  cAl  =  c* ( <c*c) "(d/2) )  & 

d>G  &  even(d)  ->  c^d  =  (c^c)  ~  (d/2) 

can  be  used  in  place  of  that  cor  responding  to  (17) 
d>0  &  o  ld  (d)  ->  w*{c~d)  =  (w*c)  *(  (c*c)  A(V2) )  & 

d>0  &  even(d)  ->  v*(c*d)  =  w*  (  (c*c)  *  (d/2) )  . 

The  benefits  of  this  simp?. if icatinn  are  more  striking  for  more 
complex  types  of  key  variables.  To  illustrate,  consider  the  oro- 
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gram  to  compute  Ackermann"s  function  in  Example  6.  The  generali¬ 
zation  obtained  from  Corollary  4  is 
f ' {<s (n) ,s  (n-1)  ,  ...  ,s(l)>)  » 

<A(s  (n)  ,A(s  (n-1)  ,  ...  ,A(s (3) ,A(s (2) ,s (1) ) )  ...  ))>. 

Since  £'  is  represented  by  f,  the  iteration  condition 
m=0  ->  <A(m,n) >=<n+l>  & 

m^O  &  n=0  ->  <A(m,n) >*<A(m-l#l) >  & 

&  nfO  ->  <A(m,n) >=<A(m-l,A(m,n-l) ) > 
can  be  used  in  place  of 


s  ( 2)  =0  -> 

<A(s(n)  ,A(s  (n-1)  ,  ...  ,A(s(3)  ,A(s(2)  ,s(l)))  ...  ) )  >  = 

<A (s (n) ,A (s (n-1) ,  ...  , A(s (3) ,s (1) +1}  ...  ))>  & 

s(2)/G  &  s  (1)  =C  -> 

<A(s (n) ,A (s (n-1) ,  ...  ,A(s (3) ,A(s (2) ,s (1) ) )  ...  ) ) >= 

< A (s  (n)  ,  A  (s  (n-1)  ,  ...  ,A(s  (3)  ,A(s  (2) -1,1)  )  ...  ))>  & 

a  sCD/0  -> 

<A(n  in)  ,A(s  (r.-l)  ,  ...  ,  A(s  (3)  ,A(c  (2)  ,n  (1)  }  )  ...  )  )  >  = 

<A(~  Kn)  ,A(s  (n-i}  i  ...  /A(r(3)/A(s(  — )  —  •.»A(Sv*-//3(-)— 1))/  ...  ))>• 

2-  Ac cc'jnizir.  j  Ur  i  form!  y  Lop1  enter,  tod  Loops 

A?  trough  the  problem  o'  recognizing  uni  for-’ p  impler-ontn  ' 
’<^00  5  is  in  genera1  nr  unsc-lvafc  Ao  problem/  tine  follO''ir.::  "pii  *.c- 
lires  room  useful  in  a  large  number  of  sit’iatrcre. 


Pc cc  j 'z  i  z :  n  j  i  c  r rn.  I  y  i  l. o  r  t "•  oop ~  c n  l*  o  v  i  *  * <3 
soc.rd*  :;  :r  nr.  *:  ion  ■■•rt  v'h4c\  t’.'.o  ’’cop  1  i ?*-; rT.V/ 


**  nr*’  r» 


I”  practice/  con  fit  ion  (3)  in  the- 
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straint  on  this  operation.  An  effective  strategy,  therefore,  is 
to  use  (5)  as  a  guideline  to  suggest  candidate  operations.  Con¬ 
ditions  (6)  and  (7)  must  be  proven  to  show  the  loop  is  uniformly 
implemented  wrt  some  particular  candidate. 

Often  the  modification  to  the  key  variable  z  in  the  loop 
body  is  performed  by  a  statement  of  the  form 
z  :=  z  #  g  (X) 

for  some  dyadic  operation  #  and  function  g.  In  this  case,  condi¬ 
tion  (5)  suggests  the  loop  may  be  uniformly  implemented  wrt  #  or 
some  directly  related  operation.  For  example,  if  #  is  associa¬ 
tive,  condition  (5)  holds  for  #.  If  #  satisfies 
(a  #  b)  #  c  =  (a  #  c)  #  b 

(e.g.  subtraction),  and  an  inverse  V  of  #  exists  satisfying 
a  #  b  *  c  <->  b  V  c  =  a 

(e.g.  addition  if  #  is  subtraction),  condition  (5)  holds  for 

Another  commonly  occurring  case  is  when  the  future  values  of 
the  key  variable  z  are  independent  of  X,  i.e. 
h"  (z,Xl)  =  h-*  (z,X2) 

for  all  z,  XI  and  X2.  This  situation  arises  most  frequently  when 
z  is  seme  data  structure  which  varies  dynamically  as  the  loop 
iterates.  Typically,  there  exists  some  particular  aspect  or  por¬ 
tion  of  the  data  structure  (e.g.  the  top  of  a  stack,  the  end  of  a 
sequence,  the  leaf  nodes  in  a  tree)  which  guides  its  modifica¬ 
tion.  A  useful  heuristic  which  can  be  employed  in  this  cir¬ 
cumstance  is  to  consider  only  operations  which  maintain  (i.e. 
keep  invariant)  this  particular  aspect  of  the  data  structure. 
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Selecting  such  an  operation  guarantees  that  the  "change"  ex¬ 
perienced  by  the  data  structure  in  the  loop  body  will  be  indepen¬ 
dent  of  any  modification  $'  and  thus  insures  condition  (5)  holds. 

In  any  case,  recognizing  uniformly  implemented  loops  and 
determining  the  operation  wrt  which  they  are  uniformly  implement¬ 
ed  is  often  facilitated  if  the  intended  effect  of  the  loop  body 
(as  regards  the  key  variable)  is  documented  in  the  program  source 
text.  Such  documentation  abstracts  what  the  loop  body  does  from 
the  method  employed  to  achieve  this  result  and  thus  makes 
analysis  of  the  loop  as  a  whole  easier. 

To  illustrate,  consider  the  following  program  to  compute  the 
maximum  value  in  a  subarray  a[i..nl  of  natural  numbers: 

m  :*  C ; 

while  i  <=  n  do 

IT  m  <  a[iT~ then  m  :=  a[i]  f i ; 

T”: =  i  +  1 
od 

(m  =  MAXIMUM (a, iO,n) } . 

If  the  effect  on  n  in  the  loop  body  were  documented  as 
m  : =  VAX (m,a [i] ) , 

its  updating  would  be  of  the  form  m  :=  m  #  a [ i ]  and  the  heuristic 
discussed  above  could  be  employed  to  help  determine  that  the  loop 
is  uniformly  implemented  wrt  #  =  "AX. 

7.  delated  Mork 

The  first  work  on  generalizing  functional  specifications  for 
loops  appears  in  [3asu  &  Misra  76] .  These  results  are  refined  in 


-31- 


I 


I 


r 


i 


Generalizing  Specifications  For  Uniformly  Implemented  Loops 

[Misra  78]  and  are  studied  in  considerable  detail  in  [Misra  79]. 
The  major  contribution  of  this  research  seems  to  be  the  identifi¬ 
cation  of  two  loop  classes  or  schemas  which  are  "naturally  prov¬ 
able."  The  first  class  is  called  the  accumulating  loop  schema 
and  can  be  viewed  as  a  (commonly  occurring)  special  case  of  the 
Type  A  loops  discussed  here.  Specifically,  a  program  in  the  ac¬ 
cumulating  loop  schema  with  associative  binary  operation  $'  in 
the  sense  of  [3asu  &  Misra  76]  is  necessarily  uniformly  imple¬ 
mented  wrt  $'  and  meets  the  criterion  for  a  Type  A  loop  presented 
here. 

The  second  of  these  classes  is  called  the  structured  data 
schema.  A  loop  in  this  class  is  uniformly  implemented  wrt  an 
operator  which  adds  an  element  to  the  data  structure  being  pro¬ 
cessed  in  such  a  way  that  it  is  not  the  "next"  element  to  be  re¬ 
moved  from  the  structure  (e.g.  recall  the  use  of  ADDUMDER  in  the 
tree  traversal  example) .  A  loop  in  this  class  necessarily  meets 
the  criterion  for  a  Type  3  loop  presented  here.  The  program  to 
compute  Ackermann's  function  does  not  fit  in  the  structured  data 
schema.  We  remark  that  the  analysis  presented  here  relies  on  the 
loo?  body  computing  a  function,  i.e.  it  relies  on  the  loop  body 
being  deterministic.  Consequently,  the  above  comments  do  not  ap¬ 
ply  to  the  non-deterministic  structured  data  loops  analyzed  in 
[Misra  79]  . 

In  [Misra  73]  the  author  states  that  the  important  common 
feature  between  these  program  classes  is  that  "  ...  they  act  upon 
data  in  a  'uniform'  manner;  changes  in  the  input  data  lead  to 
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certain  predictable  changes  in  the  result  obtained."  The  work  we 
have  described  can  be  viewed  as  an  attempt  to  characterize  this 
commonality  and  to  generalize  the  work  in  [Misra  79]  based  on 
this  characterization. 

More  recently,  [Basu  80]  considers  the  problem  of  generaliz¬ 
ing  loop  specifications  and  uses  the  idea  of  a  loop  being  "uni¬ 
form  over  a  linear  data  domain."  One  difference  between  this 
work  and  that  presented  here  is  that  Basu  considers  only  programs 
in  the  accumulating  loop  schema  (in  the  sense  of  [Basu  &  Misra 
76]  without  the  closure  requirement) .  More  importantly,  Easu's 
idea  of  uniform  behavior  is  based  on  the  behavior  of  the  loop  as 
a  whole  and  seems  to  be  largely  independent  of  the  loo?  body. 
Our  approach  relies  solely  on  the  characteristics  of  the  loop 
body. 


Misra  points  out  in  [Misra  78,  Misra  79]  that  the  iteration 
condition  for  his  structured  data  schema  can  be  simplified  in  a 
manner  similar  to  that  presented  here;  our  results  show  that  the 
same  simplification  can  be  applied  to  his  accumulating  loop  sche¬ 
ma.  Again,  an  appropriate  view  of  our  research  is  one  of  gen¬ 
eralizing  this  earlier  work  by  investigating  the  theory  *’hich  un¬ 
derlies  these  phenomenon. 

j3.  Summary  and  Conclusions 

It  is  felt  that  the  key  to  reading,  understanding  ana  veri¬ 
fying  program  loops  is  generalizing  the  behavior  of  the  loop  over 
a  restricted  set  of  inputs  to  that  over  a  more  general  set  of  in- 
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puts.  The  view  of  this  generalization  process  presented  here  is 
one  of  ascertaining  how  changes  in  values  of  particular  input 
variables  affect  the  subsequent  computation  of  the  loop.  This 
process  is  facilitated  if  these  changes  correspond  to  particular¬ 
ly  simple  modifications  in  the  result  produced  by  the  loop  body. 

Of  course,  the  simplest  possible  modifications  in  the  result 
produced  by  the  loop  body  would  be  no  modifications  at  all,  i.e. 
the  output  of  the  loop  body  (and  hence  the  loop)  is  completely 
independent  of  changes  in  these  input  variables.  This  situation, 
however,  occurs  rarely  in  practice  since  it  implies  that  the  in¬ 
put  values  of  these  variables  serve  no  purpose  in  view  of  the  in¬ 
tended  effect  of  the  loop.  It  is  felt  that  the  definition  of  a 
uniformly  implemented  loop  presented  here  is  the  "next  best"  al¬ 
ternative,  and  yet  a  large  number  of  commonly  occurring  loops 
seem  to  possess  this  property.  The  definition  states  that  in- 
terms  of  the  execution  of  the  loop  body,  prescribed  changes  in 
the  input  value  of  the  key  variable  affect  only  the  final  value 
of  the  key  variable;  all  other  final  values  are  independent  of 
the  change.  Just  as  importantly,  the  modification  caused  in  the 
final  value  of  the  key  variable  is  necessarily  the  sane  as  the 
change  in  its  corresponding  input  value,  "his  property  is  analo¬ 
gous  to  that  possessed  by  a  function  of  1  variable  with  unit 
slope  in  analytic  geometry:  increasing  the  input  argument  by 
some  constant  causes  the  function  valua  to  be  increased  by  exact¬ 
ly  the  sane  quantity.  Taken  together,  these  factors  account  for 
the  pleasing  symmetry  between  *?  and  y  in  condition  (3). 
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Viewed  as  a  verification  technique  for  uniformly  implemented 
loops,  the  procedure  described  here  can  be  thought  of  as 
transforming  the  problem  of  discovering  the  general  loop  specifi¬ 
cation  into  the  problem  of  discovering  the  operation  with  respect 
to  which  the  loop  is  uniformly  implemented.  Clearly,  this  is  of 
no  benefit  if  the  latter  is  no  easier  to  solve  than  the  former. 
In  many  cases,  however,  it  seems  that  simple  syntactic  checks  are 
sufficient  for  identifying  this  operation.  For  example,  in  the 
tree  traversal  program,  the  fact  that  the  loop  body  does  not  test 
the  stack  for  emptiness  [Basu  &  Misra  76]  is  a  sufficient  condi¬ 
tion  for  the  loop  being  uniformly  implemented  with  respect  to 
AUDUNDER. 

It  is  felt  that  the  notion  of  uniformly  implemented  loops 
may  have  an  application  in  the  program  development  process. 
Specifically,  when  designing  an  initialized  loop  to  compute  some 
function,  the  programmer  should  attempt  to  construct  the  loop  in 
such  a  way  that  it  is  uniformly  implemented  with  respect  to  seme 
easily  stated  operation.  Our  work  indicates  that  these  loops  are 
susceptible  to  a  rather  routine  form  of  analysis.  Furthermore, 
implementing  a  loop  in  a  uniform  fashion  requires  maintaining  a 
certain  amount  of  independence  between  program  variables  (or 
perhaps  portions  of  program  variables  in  the  case  of  structures) 
and  a  simple  dependence  between  the  input/output  values  computed 
by  the  loop  body.  Such  programs  are  desirable  since  the  ease 
with  "hich  a  loop  can  be  understood  ’emends  largely  on  the  com¬ 
plexity  of  the  interactions  and  interconnections  among  program 


-36- 


Generalizing  Specifications  For  Uniformly  Implemented  Loops 


variables.  We  remark  that  the  question  of  whether  a  given  pro¬ 
gram  is  "well  structured"  has  been  viewed  largely  as  a  syntactic 
issue  (e.g.  use  of  a  restricted  set  of  control  structures);  we 
offer  the  definition  of  a  uniformly  implemented  loop  as  an  at¬ 
tempt  at  a  characterization  of  a  semantically  well  structured 
program. 
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